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AX7DIENCE MANAGEMENT FOR INTERACTIVE NETWORK EVENTS 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of D,S- Provisional 
Application No, 60/105,578, filed October 26, 1998. 

BACKGROUND OF THE INVENTION 

The invention relates to a system and method for 
managing content distribution to an audience and, more 
particularly, to a system and method for regulating access 
to network-based events such as a method for issuing 
electronic tickets to specific customers or clients, and 
accepting redemption of those tickets, thereby permitting 
customers or clients having valid electronic tickets to 
access the network-based events. 

The Internet is a loose network of connected computers 
spread throughout the world. A message can be sent from any 
computer on the Internet to any other by specifying a 
destination address and passing the message from computer to 
computer via a series of "hops." Each computer, router, or 
"node" on the Internet has a unique Internet address. When 
an intermediate computer or router receives a message in 
transit, the computer checks the intended destination of the 
message and passes it along accordingly. 

The Internet is growing, in terms of both size and 
sophistication, at a rapid rate. In the past, most users of 
the Internet were academic, research, or institutional 
users; the Internet was primarily used at that time to 
transmit and receive electronic mail and network news and to 
allow transfer of computer files. However, since the 
introduction of the World Wide Web (also known as the "Web" 
or "WWW") several years ago, the Internet has begun to host 
increasing amounts of other types of data of general 
interest, namely representations of images and articles, 
audiovisual and multimedia content, etc. 

The Web protocol and language establish a graphical 
means to navigate the Internet. "Web pages," often 
consisting primarily of text and graphical material, are 
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stored on nximerous computers, known as "Web servers," 
throughout the Internet, A software program known as a 
"browser" can be used to access and view Web pages across 
the Internet by specifying the location (i.e. Internet 
address) of the desired Web page. When a Web page is 
accessed, its information is transmitted from the remote 
computer (server or delivery site) , wherever in the world it 
may be located, across the Internet, to the user. 

In recent times, the Web has begun to host highly 
sophisticated types of multimedia content, such as audio and 
video data, and computer software. Compared to first 
generation Web content, namely text and still images, audio 
clips, video clips, and software programs have extremely 
high storage and bandwidth requirements. 

At present, it is difficult, if not impossible, to 
provide sustained high-speed transmission of large 
audio/ video files over a multi-node link on the Internet. 
Because the data is often transferred from afar, many 
factors can cause the delay or even loss of parts or all of 
a transmission. It is generally not critical if a user 
experiences minor delays in receiving small graphic or text 
files. However, it is recognized that real-time data such 
as video has very specific and stringent timing requirements 
for data transfer and display. 

Unfortunately, the present design of traditional 
Internet-like data networks is based on the principle that 
delays and significant data transmission rate variations are 
acceptable for ordinary data (e.g. text and still images) . 
Consequently, because of the high value of permitting access 
to text and graphical information from locations around the 
world, such transmission defects are considered acceptable, 
and the base capacity of the Internet is somewhat 
"oversubscribed" to reduce data transmission costs. In 
other words, the timeliness of network data transmission has 
been significantly compromised in order to render relatively 
insignificant the aggregate cost of long distance 
communication connections. 



PCT/US99/25188 

WO 00/25248 

3 

In order to successfully transfer audio-video data 
across a message-oriented network such as the Internet^ for 
any more than a few users, network resources should be 
committed in a manner facilitating timeliness of 
transmittal • A system using committed network resources 
generally cannot take advantage of the existing pricing 
method of shared networks like the Internet, since it cannot 
participate in the sharing of network resources on a data 
packet by data packet basis. Video data must be transmitted 
to the exclusion of lower-priority data. Transmission costs 
thus become significant, especially when the connection is 
"long distance" or when the connection is continued over an 
extended period of time. 

As discussed above, a browser program can be used to 
access and view Web pages across the Internet by specifying 
the location (i.e. Internet address) of the desired Web 
page, or more commonly, by "hotl inking" to Web pages. 
Common browsers are Lynx, NCSA Mosaic, Netscape Navigator, 
and Microsoft Internet Explorer* The desired Web page is 
specified by a uniform resource locator ("URL"), indicating 
the precise location of the file using the syntax 

"http : / / internet . address/directory / filename . html" . 

Web pages are generally described, in terms of layout 
and content, by way of a language known as "HTML" (HyperText 
Markup Language) • Any particular computer linked to the 
Internet can store one or more Web pages, i.e. computer 
files in HTML format, for access by users. 

Hotl inking from one HTML Web page to another is 
accomplished as follows. The user first accesses a Web page 
having a known address, often on the computer located at the 
user's ISP (Internet Service Provider). The ISP is the 
organization providing Internet connectivity to the user. 
That Web page can contain, in addition to textual and visual 
data specified in HTML format, "links," or embedded 
information (in the form of URLs) pointing to the Internet 
addresses of other Web pages, often on other computers 
throughout the Internet. The user, by selecting a link 
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(often by pointing and clicking with a mouse) , can then 
access other Web pages, which can in turn contain further 
data and/or additional links. 

Various extensions to HTML, such as the EMBED tag, 
allow references to other data to be embedded into Web 
pages. Some browsers are not capable of handling data other 
than text and images. Other browsers can handle the data in 
various ways. NCSA Mosaic, for example, handles references 
to unknown types of data by allowing the data to be 
downloaded to the user's computer, and then optionally 
invoking an external program to view or manipulate the data. 
Recent releases of Netscape Navigator and Microsoft Internet 
Explorer take the concept one step further: a browser 
extension, or "plug-in," can be automatically invoked to 
handle the data as it is received from the remote Web page, 
other means, such as network program "applets" written in 
the Java language (or a similar language) , can be used to 
extend the functionality of the browser environment or 
network . 

Traditionally, outside of the Internet, the primary 
method for communicating electronically with a substantial 
number of customers or users has been broadcasting. Radio, 
television, and other media all use various forms of 
broadcasting. Although it is possible to reach large 
numbers of people this way, it is difficult to regulate 
distribution and receipt of the content. 

In cable television systems, the unauthorized receipt 
of content is regulated by either blocking the signal before 
it reaches unauthorized individuals, or by encoding the 
transmissions and providing authorized individuals with 
decoders. Both approaches are capital-intensive, as 
blocking equipment must be installed for each unauthorized 
viewer in the former case, and decoders must be provided to 
authorized viewers in the latter case. 

It is also possible to reach large numbers of customers 
by replicating content and sending individual copies to each 
customer. Printed matter, such as newspapers, magazines are 
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distributed this way. Videotape rentals may also be 
considered to fall within this model. The Internet, while 
it uses electronic distribution like traditional 
broadcasting, acts in most cases more like the distribution 
of replicated content. Using the traditional model, 
Internet communications generally will not reach their 
intended destination unless they are specifically 
transmitted to that user. This method of reaching a large 
number of customers is inefficient, however. As described 
above, audio and video transmissions over the Internet are 
bandwidth intensive, and sending such data to a large number 
of customers can easily oversubscribe network capacity. 

Still, it is often desirable to "unicast" streams to 
large numbers of users since much information can be 
collected about the user in this one to one communication. 
The Internet is the most measurable medium in existence. It 
is absolutely the goal of the publisher to know exactly why 
and how their viewers used the content stream (s) . It is 
this specific knowledge of the user that establishes 
significant value to the provider and its advertisers. 
Unfortunately, Internet Multicasting or broadcasting 
forfeits the opportunity of user data while not capitalizing 
on the truly efficient cost advantages of the traditional 
broadcast infrastructure. 

The actual problem is three fold. One. Whereas 
broadcast television in the early days had only three 
networks, we have now 50 broadcast and cable stations and 
millions of Web sites. Thus, the competition for viewership 
is fierce. Even in the best scenario, it is difficult to 
capture and hold viewers. This new Internet community of 
viewers migrates from site to site. No one has a favorite 
channel. This means that very few sites have regular or 
consistent traffic. In fact, to collect traffic at all, 
sites have to become increasingly specialized. When there 
were 3 broadcast networks they each carried variety content. 
Now that there are 50 cable stations, each one has to have 
specialty or niche content in order to attract and maintain 
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an audience. Since these Internet "TV stations" have 
smaller audiences, they must increase the value of their 
audience to the advertiser by increasing their understanding 
of each viewer in the audience. 

Second. As content becomes more specialized, the body 
of data changes less frequently. Therefore, the viewer has 
less reason to frequently return to the site. Yet broadcast 
television is about creating habit. What kind of viewership 
would Seinfeld have if its show date & time varied week to 
week? No viewer would set aside the time to watch the 
program. Audience building is about creating habit. If the 
content is not changing regularly than one has little hope 
of creating habit. The publisher's only hope is to reach 
out and bring the viewer back mechanically. 

So, the goals of Internet publishing have to include 
habit-forming processes or mechanisms that replace habit 
while at the same time capturing as much information about 
the viewer as possible. 

Third. Unicast streams are profoundly expensive at any 
level of data rate. The optimal configuration would be to 
know exactly how many streams are required to support the 
program for the attending audience. It's like buildinig 
airliners for just the number of travelers of that day. If 
this were possible, airline travel would be significantly 
cheaper. Similarly, a unicast network configuration would 
also benefit with this type of planning optimization. 

The early years of the Internet created navigation 
structures that merely funneled people by Web content. That 
is, sites get out and establish what is routinely called 
"distribution." Distribution is a collection of links that 
siphon people off of one site on to new sites or pages. 
This traffic translates directly into dollars for the Web 
publisher. To be truly effective however, Web publishers 
need to create "programming" processes that more dynamically 
steer viewers to the type of content the user desires to 
see. The result must become something akin to an amusement 
park ride. The user needs to be "driven" past sites and 
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information interesting to the user, rather than be exposed 
to a continuous stream of loosely related messages and 
images . 

The principle shift for sites is to present Web site 
5 facades that deliver different messages for different users. 
Advertising on the Web has already made this shift as have 
Internet search engines with content preferencing. The goal 
in communication is to speak to each user. What do you do 
for them? The problem is that the broader the message, the 

10 smaller the impact it has on the specific user. The new 
mission of the Internet communicator is to both sharpen 
one's point while getting to that point much faster. Focus 
and brevity are the catchwords of a viable site. 

There is also an Internet-based form of broadcasting, 

15 which in one embodiment is called "multicasting." In this 
case, an Internet-based communication can reach a large 
number of users, but can also be intercepted easily by 
individuals who are not authorized to do so. Internet 
broadcasts, like traditional television broadcasts, are 

20 difficult to regulate. Audio and video content distributed 
this way can be encrypted or specially encoded to prevent 
unauthorized viewing, but this often does not present 
desirable results. The computational and storage 
capabilities of many computer systems in common use today 

25 are over-burdened or fully utilized simply in the process of 
receiving and decoding audio and video content. The extra 
computational resources necessary to decrypt audio and/or 
video data, as well, frequently results in degraded content 
quality for a majority of users. 

30 Accordingly, there is a need for the ability to 

regulate access to Internet content that can be distributed 
to a potentially large number of individuals. This ability 
to regulate access should be robust, capable of tracking 
usage, and easy to use. 
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SUMMARY OF THE IMVENTION 

The invention relates to a system and method for 
managing content distribution. In one embodiment, the 
invention defines a system and method for both regulating 
and promoting access to Internet content or other events by 
fostering reservations and issuing electronic tickets to 
authorized individuals or ideal audiences in advance of the 
event . 

A presently preferred embodiment of the invention 
includes an event guide, which includes information on when 
events will take place, what content is included, cost, and 
restrictions on attendance. The event guide is also used as 
an "alarm clock" and virtual host for the collection of pre- 
registered viewers prior to the commencement of the event. 
The goal is to identify end users and collect them as the 
audience for the event. 

Limiting event attendance to a certain number of 
authorized individuals is contrary to current Internet 
paradigms, but is useful for several reasons. First, access 
may be restricted to those individuals who have paid for it, 
as in "pay-per-view" television. This tends to increase the 
value of the event. Second, it allows the number of 
attendees to be predicted, so that equipment and bandwidth 
needs can be assessed prior to the event. Because of this, 
the drain on scarce network resources can be regulated, 
resulting in more efficient allocation of network resources. 
Third, the individuals who have the greatest interest in an 
event can be targeted. Not only does the sequence of 
affirmative steps required to procure and present an 
electronic ticket deter the most casual users, but the 
registration process of the invention allows demographic 
data to be collected for all users who request tickets. 
Moreover, because tickets can be redeemed at the time of the 
event, the invention can also track attendance; a benefit of 
interest to event sponsors. Maybe more impprtantly, a goal 
of all "selling" is to create scarcity of the item to be 
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sold. The greater the perceived scarcity, the higher the 
market value of the item. 

Another goal of the system is to reduce cost of 
promotion. Ordinary promotion of an event is transitory and 
will diminish dramatically once the event has come and gone. 
If the content provider instead focuses on collecting 
viewers for each event using the system described here, the 
total magnitude of viewers will increase as a consequence of 
the number of events staged. This existing base of end 
users (subscribers) can then be used by the content provider 
to laterally grow the type and diversity of their content 
offerings. 

In one embodiment, the invention also includes a method 
to encourage participation once tickets have been acquired. 
Specifically, if a user does not use tickets he has 
reserved, even when there was no monetary cost for the 
tickets, participation in future events may be denied or 
conditioned. 

With the system and method of the invention, payment 
possibilities are flexible, and are not even required. 
Certain tickets may be charged to the requesting user's 
credit card, and certain other tickets may be acquired free 
of charge, as desired by the operator of the ticketing 
system. Charges may be made to the user at any time, when 
reservations are made, when a ticket is acquired, or when 
the event takes place. 

To accomplish the method of the invention, the user's 
terminal exchanges information with a database server and a 
registration server by way of a custom ticketing program 
operative for example, at the user terminal. Reservations 
are requested from the database server. If the user is 
authorized to attend the event, and space is available, then 
the registration server processes and issues the user's 
ticket. When the event occurs, the user redeems the ticket 
by presenting a code to the server. If the code is 
authorized, the user terminal will begin receiving data. 
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BRIEF DESCRIPTIOH OP THE DRAWINGS 

FIGURE 1 is a block diagraiD illustrating several 
functional blocks, namely a plurality of servers and at 
least one user terminal, as used in an embodiment of the 
invention; 

FIGURE 2 is a block diagram illustrating the 
intercommunication among the various blocks illustrated in 
FIGURE 1; 

FIGURE 3 is a flowchart illustrating a method by which 
a reservation is requested according to an embodiment of the 
invention; 

FIGURE 4 is a flowchart illustrating a method by which 
ticket availability is confirmed according to an embodiment 

of the invention; 

FIGURE 5 is a flowchart illustrating a method by which 
attendance at an event is authorized according to an 
embodiment of the invention; 

FIGURE 6 is a diagram illustrating one possible user 
interface method for an embodiment of the invention; 

FIGURE 7 is a diagram illustrating operations related 
to how information may travel through an audience management 
system constructed according to an embodiment of the 
invention; 

FIGURE 8 is a diagram illustrating operations related 
to registering in an audience management system constructed 
according to an embodiment of the invention; 

FIGURE 9 is a diagram of a screen display that 
describes new stories and events in an audience management 
system constructed according to an embodiment of the 
invention; 

FIGURE 10 is a diagram illustrating operations related 
to viewing content and recording activity in an audience 
management system constructed according to an embodiment of 

the invention; 

FIGURE 11 is a diagram of two screen displays that 
describe a channel changer in an audience management system 
constructed according to an embodiment of the invention; 
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FIGURE 12 is a diagram of two screen displays that 
describe a ticket minder in an audience management system 
constructed according to an embodiment of the invention; 

FIGURE 13 is a diagram of two screen displays that 
5 describe the process of accessing an about screen in an 
audience management system constructed according to an 
embodiment of the invention; 

FIGURE 14 is a diagram of two screen displays that 
describe the process of accessing a help screen in an 
10 audience management system constructed according to an 
embodiment of the invention; 

FIGURE 15 is a diagram of a navigation screen display 
in an audience management system constructed according to an 
embodiment of the invention; 
15 FIGURE 16 is a diagram of a screen display that 

describes a method of sorting items in an audience 
management system constructed according to an embodiment of 
the invention; 

FIGURE 17 is a diagram of a screen display that 
20 describes a method of displaying events in an audience 

management system constructed according to an embodiment of 
the invention; 

FIGURE 18 is a diagram of a screen display that 
describes a method of confirming a ticket in an audience 
25 management system constructed according to an embodiment of 

the invention; 

FIGURE 19 is a diagram illustrating operations related 

to obtaining a ticket in an audience management system 

constructed according to an embodiment of the invention; 
30 FIGURE 20 is a diagram of a screen display that 

describes a method of accessing more information about an 

event in an audience management system constructed according 

to an embodiment of the invention; 

FIGURE 21 is a diagram illustrating operations related 
35 to registering a publisher in an audience management system 

constructed according to an embodiment of the invention; 
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FIGURE 22 is a diagram of a main publisher screen 
display in an audience management system constructed 
according to an embodiment of the invention; 

FIGURE 23 is a diagram of a screen display that 
describes a method of creating a new entry in an audience 
management system constructed according to an embodiment of 
the invention; 

FIGURE 24 is a diagram illustrating operations related 
to creating a new entry in an audience management system 
constructed according to an embodiment of the invention; 

FIGURE 25 is a diagram illustrating operations related 
to uploading an entry in an audience management system 
constructed according to an embodiment of the invention; 

FIGURE 26 is a diagram of a choice list screen display 
in an audience management system constructed according to an 
embodiment of the invention; 

FIGURE 27 is a diagram illustrating operations related 
to downloading statistics in an audience management system 
constructed according to an embodiment of the invention; 

FIGURE 28 is a diagram of two screen displays that 
describe the demand reports in an audience management system 
constructed according to an embodiment of the invention; and 

FIGURE 29 is a diagram of a screen display that 
describes a method of uploading media files in an audience 
management system constructed according to an embodiment of 
the invention • 

DETAILED DESCRIPTION OF THE INVENTION 

The invention is described below, with reference to 
several detailed illustrative embodiments. It will be 
apparent that the invention can be embodied in a wide 
variety of forms, some of which may be quite different from 
those of the disclosed embodiments. Consequently, the 
specific structural and functional details disclosed herein 
are merely representative and do not limit the scope of the 
invention. 
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Referring initially to FIG. 1, the Internet 110, which 
is intended to be representative of wide-area communications 
networks in general, is depicted in the center. The 
Internet is known to be an interconnected network of a large 
number of computers. Although Internet-connected computers 
that are "geographically" near each other can be 
"electronically" near each other on the Internet, such is 
not usually the case. However, one computer connected to 
the Internet can communicate with any other computer 
connected to the Internet; the message will most likely 
travel over a path comprising a sequence of links, or 
"hops," between computers that are directly connected to 
each other. 

A user terminal 112 is also depicted in FIG. l. The 
user terminal 112 is connected to the Internet 110 via an 
Internet service provider (ISP) , which is typically a 
computer, router, or terminal server connected to the 
Internet 110. Only one user terminal is shown; however, it 
should be recognized that the number of concurrent users of 
the invention is potentially unlimited. 

Also connected to the Internet 110 are a ticketing 
server 114, a database server 116, a registration server 
118, and an event server 120. As will be described in 
further detail below, these servers are employed in a system 
according to the invention to issue and process electronic 
tickets. 

A browser program 122, as is well known in the art, is 
adapted to run on the user terminal 112. This browser 
program 122 is capable of sending and receiving data from 
the Internet, and is further capable of displaying data in a 
graphical format. Examples of popular browser programs in 
common use are Netscape Navigator and Microsoft Internet 
Explorer. As is also well known in the art, the browser 
program 122 is capable of interfacing with an e-mail program 
124. 

A custom ticketing program 126 is provided for use with 
the invention. In a presently preferred embodiment, the 
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ticketing program 126 is in the form of a "plug-in" for use 
in cooperation with the browser. Alternatively, the 
ticketing program may be a standalone program, an "ActiveX 
control" for use with Microsoft Internet Explorer, or a Java 
application or applet for use in cooperation with a browser 
or operating system capable of interpreting or compiling 
programs in the Java language. 

The functional relationships among the various programs 
running user terminal 112, the ticketing server 114, the 
database server 116, the registration server 118, and the 
event server 120 are illustrated in Figure 2. 

The Ticketing/Guide program 12 6 first interacts with 
the ticketing server 114; requests for information on 
ticketed events are sent from the user terminal 112 to the 
ticketing server 114 (arrow 210) . The ticketing server 114 
responds by sending back a list of events. 

Preregistration information and requests for 
reservations are sent from the Ticketing/Guide program 126 
to the database server 116 (arrow 214) . After a request is 
received, the database server 116 sends a confirmation 
message and information on the event back to the browser 
program 122 (arrow 216) . The database server 116 also sends 
an e-mail confirmation message to the e-mail program 124 
(arrow 218) . 

As will be described below with reference to Figure 4, 
the e-mail confirmation message requires a response by the 
user. That response is sent from the e-mail program 124 (or 
optionally the browser program 122) to the database server 
116 (arrow 220) . The database server communicates its 
receipt of the user's response to the registration server 
118 (arrow 221), which in turn interacts with the browser 
program 122 to communicate reminders, payment information, 
and any other desired information between the user terminal 
112 and the registration server 118 (arrow 222). Once 
payment and any other additional details have been processed 
by the registration seirver, the electronic ticket, namely an 
authorization for the user to attend the event, is sent from 
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the registration server 118 to the ticketing program 126 
(arrow 224); the event server 120 is also advised of the 
user*s authorization (arrow 225). 

At or about the time of the event to be attended, the 
user terminal 112 is connected to the event server 120. The. 
ticketing program 126 redeems the electronic ticket by 
presenting the authorization code previously received from 
the registration server 118 (arrow 226) . If authorization 
is granted, the event server 120 then begins to send the 
event data to the browser program (arrow 228). 

Figure 3 illustrates in further detail the sequence of 
steps performed by the invention at the time a user 
identifies and requests to participate in an event. 
Initially, in a preferred embodiment of the invention, the 
user preregisters to use the ticketing service (step 310) . 
This is accomplished by having the user send his full name, 
address, telephone number, payment information (such as a 
credit card number) , and any other desired information to 
the database server 116, where that information is stored 
for later use. After preregistration has been completed, 
the user is free to use the ticketing service. 

When the user has identified an event of interest (step 
312) , for example a live concert presented in audio and 
video, the user indicates his selection to the ticketing 
program 126 or to the browser program 122, e.g., by clicking 
on a button corresponding to the selected event. 

In this embodiment of the invention, the event can be 
identified by one of at least three ways: by noting its 
listing in the event guide presented by the ticketing 
program 126 (Figs. 1 and 2), by visiting a Web site that 
advertises the event, or by word of mouth. In the first 
case, the ticketing program 126 is used to browse or search 
a list of upcoming events; this list is typically (but need 
not be) received periodically or upon request from the 
ticketing server 126. With the first alternative, the 
ticketing program 126 is already being run, and selecting an 
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event in the listing of events will cause the ticketing 
program to proceed in the ticketing process. 

In an embodiment of the second case, when the user 
notes the existence of an event via a Web advertisement, the 
advertisement typically would include a hyperlink to another . 
Web page, which includes code (e.g., the EMBED statement) 
adapted to invoke the ticketing program 126 • When this 
approach is followed, the code may also include information 
on which event is desired, thereby enabling the ticketing 
program 126 to proceed in the ticketing process without 
further input from the user. 

In the third case, when the user learns of an event 
from external sources, such as word of mouth, the user can 
either search the listing of events with the ticketing 
program 126 or can enter a specific Internet address into 
the browser program 122, thereby loading a Web page 
containing code adapted to invoke the ticketing program, as 
in the second alternative described above. 

A reservation is then requested by transmitting the 
user's request from the user terminal 112 to the database 
server 116 (step 314) • The database server 116 then checks 
for the availability of tickets to the event (step 316). 
For example, a concert event might be limited to 10,000 
attendees. In this case, if the user is one of the first 
10,000 individuals to request a reservation, then a message 
confirming ticket availability is immediately sent via e- 
mail to the user terminal (step 318). If not, then a message 
confirming placement on a waiting list can be sent to the 
user; when (and if) space becomes available later, the 
confirmation e-mail would then be sent. 

Finally, a record is added to a database on the 
database server 116 (step 320) representative of the user's 
confirmation or position on the waiting list. If the user 
is on the waiting list, no further action need be taken 
unless additional spaces open up. 

Figure 4 illustrates the procedure followed by the 
database server after a reservation request has been placed 
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by a user (under the procedure of Figure 3) . For each user 
who has placed a reservation request, the database server 
116 waits (step 410) until space opens up to acconunodate 
that user, based on the user's priority. As described 
above, there may be a limited number of available tickets. 
If some users who have previously made reservations fail to 
respond to their confirmation within a predetermined time 
period, if the event's capacity is increased, or if some 
previously registered users cancel their reservations (as 
described below] , additional tickets may become available 
(step 412) . 

When a ticket becomes available, an e-mail message is 
sent to the user (step 414). In a presently preferred 
embodiment of the invention, this e-mail message includes 
computer code (e.g., in HTML or the Javascript language) 
adapted to present a response button to the user through the 
e-mail program 124. Many e-mail programs in common use 
today are capable of decoding HTML or Javascript content; 
several other programs are capable of automatically invoking 
a browser program to decode the HTML or Javascript. In 
either case, the user is presented with a response button, 
and the system awaits completion of the confirmation process 
(step 416) by awaiting a message from the user terminal 112, 
sent when the user presses the response button. 

When the response has been received by the database 
server, a final registration page is sent to the user's 
browser program 122 (step 418) . This registration page 
includes a registration program capable of interacting with 
the ticketing program 126. This registration program is run 
at the user terminal 112 (step 420) ; it receives the 
authorization code from the registration server 118 (step 
422) as well as further information on the event, including 
a request to authorize a credit card payment, if applicable 
(step 424). Payment authorization is then transmitted from 
the user terminal 112 to the registration server (step 426) , 
and a countdown timer is initiated (step 428) to remind the 
user of the event. 
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While the processing of a credit card payment is 
disclosed at step 424 above, it should be noted that payment 
is possible at other times during the method of the 
invention. For example, a payment could be made at the time 
a reservation is requested (step 314), or at the time of the 
event (see Figure 5, described below). Tickets for certain 
events might not be charged at all. 

In one embodiment of the invention, the user is allowed 
to cancel a ticket reservation at any time before a ticket 
is received (step 426) • If payment has already been made, 
and the cancellation is received before a threshold time or 
date, the system can be enabled to issue a refund to the 
user. Alternatively, some events may be designated as non- 
refundable. 

As described above, at the time of the event, the user 
accesses the event server 120. The interaction between the 
user terminal 112 and the event server is described in 
detail with reference to Figure 5. Initially, the user 
activates the browser program 122 to access the event server 
120 (step 510) . The event server then waits (step 512) 
while the ticketing program 126 is activated (for example, 
by an EMBED code in the page referenced by the browser 
program 122) and the ticketing program then sends the 
authorization code to the event server 120. If the code 
received by the event server is invalid (step 514) , then the 
user's attempt to access the event is rejected (step 516) • 
If the code is valid, then the user is allowed to 
participate (step 518) . 

The database server 116 is updated with information on 
the user's attendance (step 520), and the event data, which 
may be audio, video, or other information, is sent from the 
event server 120 to the user terminal 112 (step 522) . In a 
preferred embodiment, once the authorization code has been 
presented and accepted by the event server 120, it is no 
longer valid for use by any other user terminal. 
Accordingly, as with traditional tickets, the authorization 
code of the invention is usable only once. 
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In one embodiment of the invention, the event server 
120 checks the validity of an authorization code presented 
to it by either checking its own internal database, based on 
information previously received from the registration server 
118. Alternatively, the event server 120 can query the 
registration server 118 each time a user attempts to access 
an event. 

In a preferred embodiment of the invention, ticket 
management is handled entirely by the ticketing program 126 
installed at the user terminal 112. The registration server 
118 automatically transfers the ticketing information to the 
user's ticketing program 12 6, and when the user accesses the 
event server 120 hosting the event, the ticketing program 
12 6 automatically transmits the proper ticket, namely the 
necessary authorization code, to the event server 120 for 
verification. 

However, certain manual steps may be desirable in 
certain circumstances. If the user successfully registers 
for an event at his home computer, but is away from that 
computer when the event is scheduled to occur, it would be 
desirable to provide for the ability to print or otherwise 
export a textual representation of the authorization code. 
Accordingly, when the user attempts to access the event from 
a remote location, the textual representation would be 
requested by the event server. 

Figure 6 illustrates an illustrative user interface for 
the ticketing program 126 of the invention. As described 
above, the ticketing program includes an event guide 
including a list 610 of upcoming events. By manipulating 
various controls on a graphical user interface, as is well 
known in the art, the user can request more information 
about a particular event (button 612) , reserve tickets for 
an event (button 614) , or cancel the operation of the 
ticketing program (button 616) . 

The user interface of the ticketing program 126 further 
includes a status area 618, in which information about 
previously reserved tickets can be displayed. In Figure 6, 
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a representation of a ticket 620 is shown, indicating that 
the user has already requested at least one ticket for an 
event. Further information on that ticket can be displayed 
by selecting the ticket 620 with a pointing device, as is 
known in the art* 

In a preferred embodiment, as illustrated in Figure S, 
the ticketing program is capable of displaying the event 
guide sorted by date (tab 622), by type of event (tab 624), 
or by artist or other participant (tab 626) . 

The ticketing method presented herein is resistant to 
duplication. As with traditional ticketing, each ticket or 
authorization code is good for only one admission to the 
event. Accordingly, the user who receives an electronic 
ticket according to the invention is responsible for the 
safe keeping of the ticket or authorization code. If the 
code is duplicated, and more than one individual attempts to 
gain access to the event, only the first individual will be 
granted access. Alternatively, other verification means can 
be used. 

While this disclosure is directed primarily to a method 
for regulating access to network-based events, it should be 
noted that the method disclosed herein could easily be 
adapted to regulate access to non-network events, as well. 
For example, tickets to actual live concerts, movies, 
airline seats, and other limited-supply items could be 
handled by various embodiments of the invention. In such 
cases, the authorization code presented to the user by the 
registration server would serve as a paperless ticket, and 
would be presented by the user to gain access. 

Multiple servers, namely a ticketing server, a database 
server, a registration server, and an event server, are 
disclosed and described in detail as separate items herein. 
However, it should be noted that the functions of some or 
all of these servers may be incorporated into one or more 
servers, with those functions divided among plural servers 
differently than disclosed herein. Moreover, the servers 
disclosed above may exist as distributed nodes in 
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communication over a network, with individual nodes 
performing only certain functions or sub-functions. 
Functions may be allocated to single, plural, or distributed 
servers according to means well known in the art« 

Referring now to Figures 7-29, one embodiment of a 
management system for managing content distribution to an 
audience of users will be described. The Audience 
Management System (AMS) is a software solution for creating 
and retaining online audiences for a Web site. With AMS, 
publishers can create and upload information from one or 
more HTML pages to the system network. Publishers can also 
gather information about their online audience or viewers 
through AMS by requesting usage data from the AMS Server and 
producing reports based on that data. 

The Audience Management System also provides: 

Secure multimedia content delivery through the 
Internet; 

Virtual ticketing to events; 

Content delivery for a community of users; 

Content maintenance; 

"Branded channel" displays for publishers; and 
Reporting. 

Audience Management System (AMS) is made up of three 
main components: 

The system network; 

Audience Management System: The Client (AMS: The 
Client) ; and 

Audience Management System: The Publisher (AMS: 
The Publisher) - 

The system network is the tool used to communicate to 
the client. Publishers create and upload information to the 
system network. 
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AMS: The Client is an application that r\ins on a 
personal computer. It is designed to provide easy access to 
secure multimedia content as set up by a Publisher. 

AMS: The Publisher is designed as an organizational 
tool for publishers. Through an easy-to-use data entry 
system, the tool creates data records that are accessed by 
Audience clients. 

In Audience Management System (AMS) , there are two 
types of users: Clients and Publishers. Publishers create 
and upload information to the system network that the 
clients will view. 

Figure 7 describes how information travels through AMS. 

1. Publisher creates and uploads information to the 
Staging Area. 

2. The information is then downloaded to the Sybase 
Database on the Database 101 Machine* 

3. From there, a process is run that takes the 
information from the Sybase Database and 
interprets the information into Channel Data, 
which is comprised of Event and Content Data. 

4. The client obtains Channel Data from the AMS 
Server when a request is made to view data. 

5. Usage Data is downloaded to the Publisher for 
report production. 

Audience Management System: The Client 

Installing AMS: The Client 

Before installing AMS: The Client, the end user must 
obtain a Channel Installation package from the publisher by 
downloading it from the publisher's Web site, CD-ROM or 
diskette. 
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The Channel Installation package contains the data 
files that comprise the Channel, and program files that 
direct the installation. EyeQ is invoked to install the 
Channel into the client's copy of AMS: The Client. 

If the client does not have AMS: The Client installed: 
1. EyeQ is invoked to download and install the AMS: 

The Client prior to installing the Channel. 
If the client does not have eyeQ installed: 

1. EyeQ will automatically be downloaded and 
installed. 

2. AMS: The Client will be installed. 

3. Channel will be installed. 

An AMS: The Client icon appears on the client's desktop 
simply labeled INTERVU, along with an eyeQ Multimedia 
Manager icon if that was not already installed. The Start 
menu entry for INTERVU is created or updated and entries for 
starting AMS: The Client as well as for uninstalling it are 
created, along with entries for installing and uninstalling 
each channel. 

Channel Installation Package 

To create a Channel Installation package, one must 
create the artwork for the channel screens and controls, 
encapsulate them into a fast-format file, and create the 
.ini file, which defines the location of the controls within 
each screen. Also, the eyeQ install scripts for the Channel 
must be created. Finally, the installation program must be 
included. 

Registering AMS: The Client 

Before launching AMS: The Client, it must be 
registered. This section explains how information is 
transferred from the User Registration dialog to the 
provider of the AMS service. 
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1. When AMS: The Client is first installed, a User 
Registration dialog appears* 

The client enters: 
Name 

E-mail address 
Covmtry 

Connection Speed 
Zip Code 

2. The client can also select a checkbox next to the 
"Send me e-mail about cool stuff" to receive 
information via e-mail about cool stuff at the AMS 
provider. 

3. When the client fills out the User Registration 
and clicks OK, the information is sent across the 
Internet to the AMS Server. 

4. From the AMS Server, the registration information 
is run with a script called evreg^cgi. 

5. The script, evreg.cgi, validates the user 
registration information and sends an e-mail 
message to the client with a confirmation number. 

6. The client replies to the e-mail message and sends 
it back to the AMS Server. 

7. The script, evreg.cgi, creates a password from the 
registration ID, User ID and e-mail address and 
sends another e-mail message to the client with a 
password . 

8. When the client replies to that e-mail message, 
the password is sent to the AMS Server and the 
script, evsignupm.cgi, makes sure that the 
password is valid. 

9. If the password is valid, a congratulations letter 
is sent to the client explaining that he/she is 
now registered. 

10. If the password is invalid, then an error message 
is sent to the client. 

11. The user registration information is stored in a 
text file called evreg.log. 
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Referring to Figure 8, the registration process 
includes the following steps: 

Step #1. Client downloads Audience Management System: 
The Client from the AMS provider Web site and fills out 
registration information. 

Step #2. Client sends user registration information to 
AMS Server* 

Step #3. Script, evreg.cgi, validates user 
registration information and sends e-mail message to client 
with a confirmation number. 

Step #4. Client replies to e-mail message and sends it 
to AMS server. The script, evsignupm, is run to make sure 
that password is valid. 

Step #5. Client receives an e-mail message explaining 
whether or not the registration process is successful. 

Navigating From Screen to Screen 

In AMS: The Client, there are three main screens: New, 
Navigate and Events. After registering the copy of AMS: The 
Client, the New screen appears. As shown in Figure 9, this 
screen lists and describes the new stories and events at a 
particular company. 

To access any of the three main screens, a client 
clicks on the Navigation buttons once, located on the left 
side of the screen. When a client clicks on a navigation 
button, the corresponding screen appears. For example, if a 
client clicks Navigate, the Navigate screen appears. If a 
client clicks Events, the Events screen appears. 
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The names of the buttons and screens are custonizable 
by the publisher, but the underlying functionality remains 
the same. 

Viewing Content 

From the New screen, a client can access information by 
selecting a topic and clicking Go There or by double- 
clicking on a topic. For example, in the NEWCO Channel, a 
client can find out about the latest promotions and events 
by selecting Promotions and Events and clicking Go There. 

1. When the client clicks Go There, an Internet 
Browser is automatically launched to view this 
information* 

2. Using the CGI script, evbeenthere.cgi, a message 
is sent to the AMS Server. The User ID and URL 
address of the Web page accessed by the client are 
stored in a log file called evhits.log. 

3. The evhits.log can include the following 
information: 

Time 
Channel 
Event 
User ID 

Ticketed or Not Ticketed Event 
URL Address 

Referring to Figure 10, the viewing content and 
recording activity process includes the following steps: 

Step #1. Client launches Web Browser when he/she 
clicks Go There. 

Step #2. CGI Script, evbeenthere. cgi, sends message to 
the AMS Server. 
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Step #3. User ID and URL address of page accessed by 
client is stored in a log file called, evhits.log. 

Changing Channels 

From the three main screens in AMS: The Client, there 
is a Channel Changer located on the bottom left side of the 
screen. When the client clicks on the Channel Changer, a 
pop-up menu appears that lists channels that have already 
been installed. The client can then change the current 
Channel by selecting another channel from the list. 

As depicted in Figure 11, the Channel was changed from 
NEWCO to MTV. When a client changes channels, he/she is 
changing the information, look and feel of the screens used 
in AMS: The Client. 

Changing Ticket Minder 

Ticket Minder is located at the bottom of the screen in 
AMS: The Client. Ticket Minder lists the events that the 
client has previously signed up for from the Events Screen. 
When the client clicks on Ticket Minder, a pop-up menu 
appears that lists the registered events. By selecting an 
event from the list, the Viewer invokes an Internet Browser 
and URL address of that particular event. See Figure 12. 
By selecting Semisonic — Breaking the Speed of Sound from 
the Ticket Minder pop-up menu, an Internet Browser is 
invoked with the URL address of the event. 

Accessing About Audience 

From the three main screens in AMS: The Client, an 
About button is located directly above the Channel Changer. 
When a client clicks on the About button, the About Audience 
Screen appears. See Figure 13. 

Accessing Help 

From the three main screens in AMS: The Client, a Help 
button is located directly above the Channel Changer. When 
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a client clicks on the Help button, an Internet Browser is 
invoked with the URL address of the Audience Help System. 
See Figure 14, To exit out of these pages, click Return To 
Audience. 

Navigation Screen 

The second main screen in AMS: The Client is the 
Navigation screen. See Figure 15. This screen clasisifies 
the stories and events from a Web site into different 
categories. It lists the categories on the left side of the 
screen and it lists the stories, events and descriptions on 
the right side of the screen. The client can change what 
he/she views on the right hand side of the screen by 
selecting different categories. 

Sorting Items 

From the Navigation screen, the client can sort the 
categories that he/she wants to view alphabetically, by 
quantity and by date. See Figure 16. The client clicks on 
the Sort drop-down list, located below the Category screen, 
and selects Alphabetic, Quantity or Newer. The list is then 
sorted according to sort criterion. The client can also 
sort items in each category for the past 1 day, 7 days or 
all days by clicking the corresponding buttons. 

Obtaining a Ticket for an Event 

The third main screen in AMS: The Client, is the Event 
screen. 

1. To get a ticket for a specific event, select 
Coming Events from the main screen and click 60 
THERE. From there, select the event you want to 
attend and click Go There. See Figure 17. 

2. After selecting Go There, a Confirm Ticket screen 
appears with your name, e-mail address and whether 
or not you want to be reminded about the event lo 
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minutes prior to it. If the information is 
correct, click sign Up. If it is not correct, 
make the necessary changes and click Sign Up. See 
Figure 18. 

3. After clicking Sign Up, the CGI script, 
evticket-cgi, verifies your information and 
creates a password using your e-mail address, user 
ID and registration ID. Then it sends the client 
an e-mail message with that information. 

4. The client replies to the e-mail message and sends 
it back to the AMS Server. 

5. Then the CGI script, evticket.cgi, checks the 
Channel Database File to see if there are any 
available tickets for the event. 

6. If so, the CGI script increases the number of 
tickets sold in the Channel Database File. 

7. The information gets stored in the following text 
file, evticket.log. 

8 . The information also gets sent out to the Event 
Database file so that the number of tickets sold 
can be updated. 

9. Finally, an e-mail message is sent to the client 
explaining that they are now officially registered 
for the event. 

Referring to Figure 19, the process of obtaining a 
ticket includes the following steps: 

Step #1. After the client clicks Go There, a Confirm 
Ticket screen appears with the name of the event, client's 
name, e-mail address and whether or not the clients wants to 
be reminded about the event 10 minutes before it occurs. If 
the information is correct, the client clicks Sign Up and 
the information is sent to the AMS Server. 

Step #2. From the AMS Server, a CGI script 
evticket.cgi verifies the user information, creates a 
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password from the client's e-mail address, user ID and 
registration ID and sends an e-mail message to the client. 
The e-mail message explains that the client must reply to 
the message if he/she wants to receive a ticket to the 
event. 

Step #3. Client replies to the e-mail message and 
sends it back to the AMS Server. 

Step #4. The CGI script, evticket. cgi, checks the 
Channel Database Files (newCo/chaninf o,dir and 
NewCo/chaninfcpag) to see if there are any available 
tickets for the event. 

Step #5, If so, the CGI script increases the number of 
tickets sold in the Channel Database Files. 

Step #6. The information gets stored in the following 
text file, evticket.log. 

Step #7. Finally, an e-mail message is sent to the 
client explaining that they are now officially registered 
for the event. 

Accessing More Information about an Event 

From the Confirm Ticket screen in Events, the client 
clicks Event Info. See Figure 20. When a client clicks on 
Event Info, this will launch a Web Browser with the URL of 
the Event Page. 

Audience Management System: The Publisher 

Registering AMS: The Publisher 

To register AMS: The Publisher, the publisher must get 
a Workstation ID Number and Activation Key number. To 
obtain these numbers, the publisher must contact the AMS 
provider. 
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In general, employees of the AMS provider will perform 
the following steps: 

1. Go to the following Url: 

httpi //evouide. intervu, net /addclient. html, 

2. From this page, enter the following information: 
Client Name 

Client Code 
User Name 
Password 
Channels 

3. click Submit. 

The Content Producer will receive a valid workstation 
ID number and activation key number that he/she enters as 
soon as the Audience Publisher Tool is launched. 

4. Publisher launches AMS: The Publisher. A 
registration dialog appiears asking for the 
Workstation ID number and Activation Key number. 
Publisher enters them and clicks OK. 

5. The registration information is sent to the AMS 
Server, which looks up the Workstation ID number 
and Activation Key number. 

6- If the information is valid, then a list of 

channels is sent to the Publisher's workstation 
from the AMS Server. 

Each time the Publisher launches AMS: The Publisher, 
the AMS Server looks up the Workstation ID number and 
Activation Key number to make sure that a valid user is 
working with the program even though he/she is not queried 
for them. 

Referring to Figure 21, the registering process 
includes the following steps: 

Step #1. The publisher. Workstation #1, installs AMS: 
The Publisher. After installation is completed, the 
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registration dialog appears. The publisher must enter the 
Workstation ID Number and Activation Key Number that is 
obtained from the following site: 
http t / /evcruid e . intervu . net /addclient . html , 

Step #2. After the publisher enters this information 
in the registration dialog and clicks OK, the information is 
sent to the Global Master Database* 

The Global Master Database consists of multiple 
databases: Channel Database and User Database. The Channel 
Database consists of the following files: chaninf o.mtv.pag 
and chaninf o.mts. dir. The User Database consists of the 
following files: user inf o.mtv.pag and userinf o.mtv.dir. 
Note that MTV is the client code and changes according to 
client accessing the information. 

Step #3. When the publisher clicks OK, the information 
is uploaded to following inbound directories across the Web: 
/home/httpd/html/ inbound/ . htaccess 
/home/ www/ evglogs/clients/ .htpasswd 
/home / www/ evg logs / clients/, htgr oup 

Step #4. Channels are downloaded to the Publisher; if 
there is an error in registration, an error message is 
returned to the Publisher. 

Main Screen 

After registering AMS: The Publisher, the main screen 
appears. From this screen, a publisher can choose to 
perform the following functions: 

Create New Entry 

Edit Entry 

Delete Entry 

Upload Entry 

Arrange "Hot" Entry 

Identify Entry by Keyword 
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Download Statistics of Viewers 

Create Content Demand Reports 

Create Top 20 Reports 

Upload Media Files to INTERVU network 
Simply select an entry and click Run. See Figure 22. 
When the publisher selects an entry and clicks Run, the 
corresponding screen appears. 

Creating New Entry 

1. From the main screen in AMS: The Publisher, select 
Create New Entry and click Run. The New Entry 
screen appears. See Figure 23. 

2. Enter the following information set forth in Table 
1: 



Field: 


Description: 


Title 


Enter the Title of the 
entry. 


Description 


Enter a brief 
description of entry. 


Link 


Enter the URL of the 

site. 


Post From 


Enter the Start Date of 
the Entry. 


Post Through 


Enter the End Date of 
this Entry. 


Type: Video; Audio; 

HTML 


Enter the Type of entry 
it is by selecting one of 
the corresponding radio 
buttons: Video, Audio or 
HTML. 


Options: Hot; Disable 


Select the Hot checkbox 
if you want the entry to 
appear in the "What's Hot or 
What's New" category. 


Categories : Keyword 


Enter the categories 



wo 00/25248 



34 



PCT/US99/25188 



Live Event 


Select this checkbox if 
the entry is going to be a 
live event. This enables 
the following options: Event 
Link, Event Date, Duration, 
Ticket Type, Number of 
Seats, Ticket Minder and 
Warning Before Event. 


Event Link 


Enter the URL of the 

site. 


Event Date 


Enter the Date of the 
event . 


Duration 


Enter the length 
(duration) of the event. 


Ticket Type: 
Restricted; Open Event 


Choose if the event is 
restricted or open* 


Number of Seats 


Enter the number of 
seats for the event- 


Ticket Minder 


Select or Deselect 
Ticket Minder option. 


Warning Before Event 


Allows you to receive a 
reminder before an event. 


Next 


Click this button to 
create another entry. 


Close 


Click this button to 
save and close the 
information you just entered 
offline. 


Cancel 


Click this button to 
cancel the entry. 



TABLE 1 



3* Click Close. 

New Entry screen closes and the information is saved 
offline in the local database. 

Referring to Figure 24, the process of creating a new 
entry includes the following steps: 



Step 1. Entry is saved offline in local Database. 
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Step 2. It is uploaded to Global Master Database when 
Publisher uploads entry* When a Publisher uploads an entry, 
he/she pulls out from the local database and uploads it to 
the Global Master Database as an ASCII Test File. As 
discussed above, the Global Master Database consists of 
multiple databases* 

Editing Entry 

1. From the main screen in AMS: The Publisher, select 
Edit Entry and click Run. The Select Entry for 
Edit screen appears. 

2. Select the entry to be edited and click Select. 
The Edit Entry screen appears. 

3. Make any changes necessary and click Close. 

The changes are saved offline into a local database. 
When the publisher uploads the entry, it is uploaded to the 
Global Master Database. 

Delete Entry 

1. From the main screen in AMS: The Publisher, select 
Delete Entry and click Run. The Select Entry for 
Delete screen appears. 

2. Select the entry that you want to delete and click 
Select. 

3. A pop-up dialog appears asking if you are sure 
that you want to delete this entry. Click YES if 
you are sure that this is the entry you want to 
delete. 

The entry is deleted from a local database. When the 
publisher uploads the entries, it is deleted from the Global 
Master Database. 
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Uploading Entry 

1. From the main screen in AMS: The Publisher, select 
Upload Entry and click Run. The Upload Media 
Files screen appears. 

2. Enter your User Name and Password and then click 
Start. 

3. The information is uploaded to following inbound 
directories across the Web: 
/home/httpd/htm/ inbound/ .htaccess 
/home/www/evglogs/clients/ .htpasswd 
/home/www/evglogs/clients/ • htgroup 

4. A CGI script, workstation. cgi, verifies your User 
Name and Password, Then it pulls the data that 
you want to upload from your local database, 
changes it to an ASCII Text File and uploads it to 
the Global Master Database* 

Referring to Figure 25, the process of uploading an 
entry includes the following steps: 

Step #1. Workstation. cgi script verifies User Name 
and Password. 

Step #2. Workstation. cgi script pulls data out from 
local database and changes it to an ASCII Text File. 

Step #3. Workstation. cgi script uploads ASCII Text 
File to Global Database* 

Arranging Hot order 

1. From the main screen in AMS: The Publisher, select 
Arrange Hot Order and click R\m. The Hot Entries 
Arrangement screen appears. 

2. Select an entry from the Hot Entries Arrangement 
screen and click Move Up or Move Down. The entry 
will move up or down in the list. 
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3. Click Close when you are done arranging the 
entries. 

4. The order of the entries is saved. 



Choice List 

1. From the main screen in AMS: The Publisher, select 
Choice List and click Run. The Choice List screen 
appears. See Figure 26. 

2. From this screen, enter keywords that you want to 
use for your entries. 

3. To enter keywords, click Insert. A dialog box 
appears. Enter the keyword and click OK. 

Publisher can also modify, delete and rearrange entries 
from this screen. 



Downloading Statistics 

1. From the main screen in AMS: The Publisher, select 
Download Statistics and click Run. The Download 
Statistics screen appears. 

2. Enter your user name and password and then click 
Start. 

3. A CGI script, evgetdata . cgi , verifies your User 
Name and Password. 

4. CGI script, evgetdata. cgi, pulls data from the 
Global Master Database with the dates selected and 
sends it back to the Content Producer as a text 
file. 

5. The downloaded data is then saved to a local 
database . 



There are four types of data log files: hits, user 
registration, ticket and channel and events. 

Referring to Figure 27, the process of downloading 
statistics includes the following steps: 
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Step #!• CGI Script, evgetdata.cgi, pulls data from 
Global Master Database with requested dates and sends it to 
the Viewer as a text file. 

Step #2. The downloaded data or text file is saved to 
the local database. 

Content Demand Reports 

1. From the main screen in AMS: The Publisher, select 
Content Demand Reports and click Run. The Content 
Demand Report screen appears. 

2. Select the checkbox next to All Channels if you 
want to select all the channels. If you want to 
select a specific channel, deselect the checkbox 
next to All Channels and select the specific 
channel from the drop-down list located below All 
Channels . 

3. Enter the start and end dates of the report. 

4. Select which type of report: Web, Live or Both. 

5. Click Preview to preview the report. 

6. Click Print to print the report. 

7. Click Close to get back to the main screen. 

Publisher downloads statistics before viewing or 
printing a report. 

Examples of sample content demand reports are depicted 
in Figure 28. 

Top 2 0 Reports 

1. From the main screen in AMS: The Publisher, select 
Top 20 Reports and click Run. The Top 20 Reports 
screen appears. 

2. Publisher selects how he/she wants to view report. 
By URL 

By Category 
By What's Hot 
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By Events 

3. Enter the start and end dates for the report. 

4. Enter the type: Web or Live 

5. Click Print to print the report, 

6. Click Close to go to the main screen. 



Uploading Media Piles 

1. From the main screen in AMS: The Publisher, select 
Upload Media Files and click Run. The Upload 
Media Files screen appears. See Figure 29. 

2. Enter User Name and Password and click Run. 

3. A CGI script verifies your User Name and Password. 

4. Then it pulls the unsent files from your local 
database and uploads it to the Global Master 
Database. 

5. From this screen, a publisher can add any file to 
the filename list and send it to the Global Master 
Database. Click ADD, navigate to the file to be 
sent to the Global Master Database, select it and 
repeat (if adding more than one file) . Finally, 
click Start to send the files to the Global Master 
Database. 



While certain exemplary structures and operations have 
been described above, the invention is not so limited, and 
its scope is to be determined according to the claims set 
forth below. 
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WHAT IS CLAIMED IS: 

1. A ticketing method for issuing tickets to an event 
to a user via an interactive computer network, comprising 
the steps of: 

identifying the event; 

receiving a request for a reservation for the event at 
a database server in communication with the computer 
network; 

confirming attendance at the event by sending a 
confirmation message from the database server to the user; 

receiving a response to the confirmation message; 

sending an authorization code from a registration 
server; 

receiving the authorization code at an event server in 
communication with the computer network; and 
allowing the user to attend the event. 

2. The ticketing method of claim 1, wherein the 
identifying step comprises locating a desired event on a 
list of events stored on a ticketing server in communication 
with the computer network. 

3. The ticketing method of claim 1, wherein the 
request for a reservation is received from the user. 

4. The ticketing method of claim 1, wherein the step 
of receiving a response to the confirmation message further 
comprises the step of processing a payment. 

5. The ticketing method of claim 1, wherein the step 
of allowing the user to attend further comprises the steps 
of: 

receiving the authorization code at the event server; 
comparing the authorization code to a list of valid 
authorization codes; and 
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if the authorization code is not valid, rejecting the 

user. 

6. The ticketing method of claim 1, wherein the step 
of confirming attendance takes place when there is an 
opening available for the user. 

7. A ticketing system for issuing tickets to an event 
on an interactive computer network, comprising: 

a ticketing server in communication with the computer 
network, wherein the ticketing server is adapted to maintain 
infojrmation on at least one ticketed event and to accept and 
fulfill requests for information from a user terminal; 

a database server in communication with the computer 
network; and 

a registration server in communication with the 
computer network. 

8. The ticketing system of claim 7, further comprising 
an event server in communication with the computer network. 

9. The ticketing system of claim 7, wherein the 
interactive computer network is the Internet. 

10. The ticketing system of claim 7, wherein the user 
terminal includes a browser program, an e-mail program, and 
a ticketing program. ^ 

11. The ticketing system of claim 7, wherein the 
ticketing program is downloaded from the ticketing server 
and installed on the user terminal. 

12. The ticketing system of claim 7, wherein the 
ticketing program is downloaded from the registration server 
and installed on the user terminal. 
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Web Server 



Step I 



Step U2 



Audience Management System Server 
AMS Server 



Step #3 



Internet 



Step #4 



Client 



Step #5 
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InterVU's Audience Management System: The Publisher 
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